Email Security

• Background Knowledge
  • Application Layer#Email
• Email Format
  • RFC 5322: header + body
    • 
  • MIME: Multipurpose Internet Mail Extensions extend RFC 5322 with enhancements
    • MIME Header
      • MIME-Version
      • Content-Type: 说明 body 中包含的数据类型，以便选择合适的算法进行发送和接收
      • Content-Transfer-Encoding: 指定如何将正文中的二进制内容编码为 ASCII 字符的机制；其中 7bit, 8bit 适用于纯文本数据，而 quoted-printable 和 base64 编码适用于二进制数据
      • Content-ID: 标识消息正文中某一部分的唯一标识符，通常用于在 HTML 电子邮件中嵌入图片或其他资源时，方便将正文中的资源链接到 HTML 代码中
      • Content-Description: 描述消息正文中某个部分的可读性
    • example

      From: [email protected] 
      To: [email protected] 
      Subject: Example message 
      Date: Tue, 28 Mar 2023 12:34:56 -0700 
      MIME-Version: 1.0 
      Content-Type: multipart/mixed; boundary="boundary-example" 
      
      --boundary-example 
      Content-Type: text/plain; charset="utf-8" 
      Content-Transfer-Encoding: quoted-printable 
      This is an example message body. 
      
      --boundary-example 
      Content-Type: application/pdf 
      Content-Disposition: attachment; filename="example.pdf" 
      Content-Transfer-Encoding: base64 
      JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PA0KL0Jhc2VGb250DQov TGVuZ3RoIDMzNw0KL1N1YnR5cGUgL1Jlc291cmNlcw0KL05hbWUgL0Yx 
      ... 
      
      --boundary-example--
      

S/MIME

• Secure/Multipurpose Internet Mail Extension

Authentication

1. sender 编写邮件内容
2. sender 用 SHA-256 算法生成一个 256-bit 签名
3. sender 使用 sender 的私钥对签名进行 RSA 加密
4. receiver 使用 sender 的公钥解密，并验证签名内容

Confidentiality 隐私性

1. sender 编写邮件内容，并生成一个随机的 128-bit 的 content-encryption key
2. sender 使用 content-encryption key 加密邮件内容
3. sender 使用 sender 的私钥对 content-encryption key 进行 RSA 加密，并将其附在发送内容中
4. receiver 使用 sender 的公钥进行解密获得 content-encryption key
5. receiver 使用 content-encryption key 对邮件内容进行解密

PGP

• Pretty Good Privacy
• Differences from S/MIME
  • Key Certification
    • S/MIME 使用 CA 或代理机构发放 X.509 证书
    • OpenPGP 允许用户生成自己的 OpenPGP 公钥和私钥，并从已知的个人或组织那里征求公钥的签名
  • Key Distribution
    • OpenPGP 在每个消息中不包含发送者的公钥；接收方需要从受 TLS 保护的网站或 OpenPGP 公钥服务器单独获取公钥
  • NIST 800-177 更推荐使用 S/MIME 而非 PGP，因为 CA 具备更高的可信度；不过 CA 本身也并非绝对安全

Sender Verification

SPF

• Sender Policy Framework
• SPF 通过在 DNS 记录中设置一组规则，允许域名所有者指定哪些 IP 地址或邮件服务器有权发送该域名下的邮件。当接收方邮件服务器收到一封来自该域名的邮件时，它可以查询该域名的 SPF 记录，以确认该邮件是否来自一个授权的邮件服务器。

DKIM

• DomainKeys Identified Mail
• 使用一对密钥（公钥和私钥）来验证电子邮件的发送方和邮件的完整性。具体来说，发送方在发送邮件时使用其私钥对邮件进行签名，并将公钥存储在 DNS 记录中。接收方邮件服务器可以使用该公钥验证电子邮件的签名，以确认该邮件是否来自发送方，并且在传输过程中是否被篡改。

DANE

• DNS-based Authentication of Named Entities
• 允许在 DNS 记录中存储公钥证书，以验证与该域名相关的通信的加密和身份验证。DANE 使用 TLSA 记录（TLS Authentication）将公钥证书与特定的域名和端口关联起来。当 TLS 连接被建立时，接收方可以在 DNS 中查找 TLSA 记录，并使用它来验证证书的真实性。

• TLSA
  • TLSA 记录是一种 DNS 记录类型，用于指定如何验证使用 Transport Layer Security（TLS）加密的服务端证书
  • TLSA 记录包含四个字段：证书使用（证书、公钥、指纹）、选择器（完整的证书、公钥）、匹配类型（完全匹配、SHA-256 哈希、SHA-512 哈希）和证书数据
  • TLSA 记录可以用于强制服务器使用特定的证书，从而增强 TLS 连接的安全性
  • 它还可以防止中间人攻击和伪造证书攻击，因为客户端可以比较证书指纹或公钥哈希以确定是否匹配 TLSA 记录中的信息
  • TLSA 记录通常用于安全敏感的网络应用程序，如电子商务网站和在线银行等。